Cloud Service Provider IAM Practice
From the CSP’s (SaaS, PaaS, or IaaS) perspective, IAM features should
be included in the cloud service’s design criteria, with the goal of
delegating user authentication and authorization to the customer using
user management and federation standards. Support for IAM features has
integration implications for both customers (e.g., single sign-on, user
provisioning) and CSPs (e.g., billing, accounting resource utilization).
For both the customer and CSP, IAM integration considerations at the early
stage of service design will help avoid costly retrofits. Hence, cloud
service architects and platform application developers should be embedding
IAM features at various stages of the product life cycle—architecture,
design, and implementation (e.g., externalize the authentication from the
application using the federation feature).
From a cloud customer perspective, the application’s IAM
capabilities (or lack thereof), such as identity federation, will impact
the cloud service governance, integration, and user experience (e.g.,
barriers to adopt the cloud service). Hence, architects, designers, and
developers of cloud applications should understand the IAM requirements of
cloud applications and bake the features into the RFP or CSP evaluation
criteria.
Enterprise IAM requirements include:
Provisioning of cloud service accounts to users, including
administrators.
Provisioning of cloud services for service-to-service
integration (e.g., private [internal] cloud integration with a public
cloud).
SSO support for users based on federation standards (e.g.,
SAML support).
Support for internal- and regulatory-policy compliance
requirements, including segregation of duties using RBAC, rules, or claims-based authentication methodology.
RBAC features promote a least-privilege-based access model where a user is
granted the right number of privileges required to perform the job.
Claims-based methodology enables some important privacy use cases
because it allows for only the user’s entitlements, not her actual
identity, to flow with messages, which allows for fine-grained
authorization without the requirement to actually embed the user’s
identity into messages.
User activity monitoring, logging, and reporting dictated by internal policies
and regulatory compliance, such as SOX, PCI, and HIPAA.
1. SaaS
One of the primary concerns of IT and business decision makers regarding
software-as-a-service applications is security management.
Although most SaaS vendors have been able to demonstrate that
their cloud-based applications are secure from an operational point of
view, there are still access control issues that organizations need to
address to ensure that their corporate data is fully secure from a
corporate policies and procedures standpoint.
It is becoming particularly important to address these issues
because SaaS applications are gaining popularity due to their low
barrier to adoption and their pay-as-you-go service model. In some cases, business units
are sidestepping IT and directly engaging with SaaS vendors, which can
lead to additional IT headaches. IT must manage risks that may come out
of this loss of visibility and control, and be able to ensure that the
right users have the right level of access to information hosted by SaaS
vendors.
Organizations considering integrating into SaaS services should
consider two major challenges for identity management:
Is the organization ready to provision and manage the user
life cycle by extending its established IAM practice to the SaaS
service?
Are the SaaS provider capabilities sufficient to automate user
provisioning and life cycle management without implementing a custom
solution for the SaaS service?
1.1. Customer responsibilities
In SaaS services, customers have limited responsibility and
available controls to secure information. In general, SaaS solutions
are multitenant and are delivered to the customer via a web browser.
The only controls that are available to the customer are IAM controls
such as identity provisioning, authentication policies (e.g., password
strength), profile configuration, and basic authorization policies
that manifest as user profiles. The following are the responsibilities
of customers from an IAM perspective:
User provisioning
User provisioning methods are typically unique to the SaaS provider.
Customers need to understand the preferred method, lag time to
activate users, and user attributes that are supported by the
SaaS service. Most often the provisioning process is manual and
may involve uploading spreadsheets or documents in XML format.
Almost all SaaS providers support bulk upload of user
identities, as that’s the most common use case for provisioning
users. Some SaaS providers may support just-in-time provisioning
where user identities are created on the fly using a
provisioning request (sometimes SPML-employed) that is usually
triggered by user activity such as the user clicking on a
hyperlink that is unique to the user identity.
Profile management
As part of the provisioning process, customers may have the
ability to create user profiles that play a role in user
authorization. User profiles such as user
and manager are an approach to assigning
entitlements to users within the SaaS application. Admittedly,
these are not sophisticated features and will require customers
to understand the flexibility and management of the
profiles.
SaaS IAM capability evaluation
Customers are responsible for evaluating the support for
IAM features such as SSO (using identity federation) by CSPs. SAML is
the de facto standard for federating identities and is now
supported by large SaaS providers (among them Google and
Salesforce.com). However, not all providers are supporting
SAML 2.0, and some may support only SAML 1.1. For
example, Salesforce.com supports SAML 1.1 while Google Apps
supports SAML 2.0. Hence, it is important to understand what
federation protocols are supported by which providers and the
integration requirements to federate and support SSO.
Investigation support
Logs and audit trails are also often needed to investigate
incidents. For example, PCI DSS requires the provider to “provide for
timely forensic investigation” if the service provider suffers a
breach. Since the SaaS provider’s logs are internal and are not
necessarily accessible externally or by customers, monitoring
(let alone investigation) is difficult. Since access to logs is
required for PCI compliance and may be requested by auditors and
regulators, make sure to negotiate access to the provider’s logs
as part of any service agreement.
Compliance management
Although the same security concerns companies already have
within their own networks—securing the network,
hardware, applications, and data—apply for companies
outsourcing their data with SaaS, trust and transparency
exacerbate the situation in cloud computing. When compliance
with government regulations such as SOX, the Gramm-Leach-Bliley Act (GLBA), and HIPAA and with industry standards such as PCI DSS come
into the scope of the data hosted in SaaS, it could be
challenging to meet those demands. In general, customers of SaaS
services are responsible for compliance management, although the
provider hosts the data. Make an effort to understand the access
control, logging, reporting, and auditing capabilities offered
by SaaS providers and assess whether those controls are adequate
to meet compliance management requirements.
1.2. CSP responsibilities
With regard to IAM, some responsibilities belong to the CSP and
some belong to the customer. Here are CSP responsibilities:
Authentication services
Unless the SaaS provider supports delegated authentication via
federation, it typically authenticates the SaaS users—usually
via a web form delivered over HTTPS—using a user identifier and static password.
Since users can be accessing the service from anywhere on the
Internet, it is up to the SaaS provider to authenticate users
based on the network trust level. For example, some CSPs can
preregister the IP address or IP range of a user’s location
(home, office, etc.) to protect data from hackers who are
stealing the user’s identity and credentials using keystroke
loggers (potentially installed on the user’s computer in a
stealthy manner). Given that authentication activity is a
precursor to the actual use of the SaaS service, it is critical
for the CSP to deliver and maintain a continuously available
authentication service.
Account management policies
CSPs should communicate the account management policies
including account lock-outs (after many login failures), account
provisioning methods, and privilege account management
roles.
Federation
CSPs supporting identity federation using standards such as SAML
should publish the information necessary for customers to take
advantage of this feature and enable SSO for their users. Such
information includes the version (SAML 1.1, SAML 2.0), a use
case implementation example, and implementation details of the
federation using the API (e.g., support for SAML using REST and
SOAP).
2. PaaS
Organizations considering extending their established IAM practices to
PaaS cloud providers have few options at their disposal. PaaS CSPs
typically delegate authentication functions using federation to the PaaS
provider’s IdP (e.g., the Google App Engine delegates authentication to Google’s
authentication service). In some cases, such as Salesforce.com’s
Force.com, there is limited support for delegated authentication and
it is usually performed without the aid of SAML assertions (e.g., it is
proprietary to each PaaS provider implementation). CSPs also supply
software components that can be invoked using programming languages
(usually PaaS-specific) to perform authentication and limited authorization.
Microsoft recently introduced the “Geneva” Claims-Based Access
Platform that is SAML 2.0 compliant (and is still in beta as of this
writing). The project’s goal is to help developers externalize
authentication, authorization, and personalization from .NET
applications, and help organizations federate users using Microsoft’s
federation offering, Security Token Service (STS). Microsoft developers could potentially utilize STS
deployed in an enterprise, and interoperate with applications that are
deployed on an Azure platform. This solution is specifically targeted
toward Microsoft customers who are interested in extending their Active
Directory directory into a cloud by way of federation. Therefore, it is
not apparent whether the Geneva Claims-Based Access Platform will
interoperate with existing SaaS and PaaS providers who are SAML 2.0
compliant.
3. IaaS
As of this writing, enterprises considering extending their established IAM
practices to IaaS cloud providers (computing and storage) have limited
or no options. Because IaaS providers provide computing or
storage-as-a-service, they do not have visibility to applications that
are hosted on the IaaS platform. Almost all IaaS providers use
Secure Shell (SSH) to log on and administer users and
credentials; few providers, such as Amazon Web Services (AWS) EC2, offer a web console to provision users, manage user
keys, and assign users to security groups that relate to the
administrative functions of IaaS.
Some of the responsibilities and challenges in managing users in
IaaS services are:
User provisioning
Provisioning of users (developers, administrators) on IaaS systems
that are dynamic in nature. Given that hundreds of systems are
provisioned for workload management, user provisioning will have
to be automated at the time of image creation and should be
policy-based. Ideally, systems should rely on corporate
directories (LDAP, Active Directory) for user management to avoid
duplication of identities on systems. However, the virtual network
topology in cloud and network security policies may interfere with
directory-based authentication schemes and should be assessed on a
per-CSP basis.
Privileged user management
Managing private keys of system administrators and protecting
the keys when system administrators leave the company (e.g., SSH
host keys).
Customer key assignment
Assigning IDs and keys required to access the service. These keys are
used for managing access to customer accounts for billing reasons,
as well as for authenticating customers to their services. For
example, Amazon assigns an Access Key ID, a Secret Access Key, an
X.509 certificate, and a
corresponding private key to every EC2 customer. You authenticate
to an AWS request using either the Access Key ID and Secret Access
Key or the X.509 certificate and private key. Hence, customers are
responsible for provisioning and safeguarding these keys.
Developer user management
Provisioning of developers and testers to IaaS instances,
and deprovisioning the same when access is no longer
required.
End user management
Provisioning users who need access to applications hosted on
IaaS.
Currently, there is no automated way to synchronize an
organizational LDAP or Active Directory directory with IaaS providers to
avoid a redundant user database at each of the IaaS clouds. Some
third-party identity management service providers claim to have
developed adapters for EC2 user provisioning and management, however.
